home *** CD-ROM | disk | FTP | other *** search
- Path: fido.asd.sgi.com!austern
- From: James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de>
- Newsgroups: comp.std.c++
- Subject: Re: Throwing an exception from within a signal handler
- Date: 24 Jan 1996 11:34:57 PST
- Organization: -
- Approved: austern@isolde.mti.sgi.com
- Message-ID: <9601241005.AA12922@lts.sel.alcatel.de>
- References: <4dgj4m$9la@engnews1.Eng.Sun.COM> <DLCosx.Hn1@falcon.daytonoh.attgis.com> <KANZE.96Jan19122409@gabi.gabi-soft.fr>
- NNTP-Posting-Host: isolde.mti.sgi.com
- X-Original-Date: Wed, 24 Jan 96 11:05:23 +0100
- In-Reply-To: kanze@gabi.gabi-soft.fr's message of 19 Jan 1996 21:03:12 GMT
- X-Auth: PGPMoose V1.1 PGP comp.std.c++
- iQBVAwUBMQaJ8ky4NqrwXLNJAQGCygH+N+OwANhei8wovaW/q85T3qfK6pLMN7x0
- zSD1IM7PsoWJnuzkYp7xmJcTzWDCSUYP2qciEsUPhW3aQ8l4TTtWfQ==
- =wEP1
- Originator: austern@isolde.mti.sgi.com
-
- G. Bowden Wise writes:
-
- |> J. Kanze wrote:
-
- |> > I use reference counted pointers a lot, but they have their own set of
- |> > problems. I can very well understand the committees reluctance to
- |> > adapt them.
-
- |> Can you share with us the problems with reference counter pointers?
- |> How do those problems compare with the auto_ptr problems? Perhaps
- |> we need some kind of hybrid between the two.
-
- The problems are not so much with use, but with how to standardize.
-
- There are two distinct approaches with regards to reference counted
- pointers: invasive and non-invasive.
-
- Invasive reference counting involves significant constraints with
- regards to the counted objects. None of the basic types meet these
- constraints, nor can they be made to. None of the other types in the
- library meet them, either. In this case, the committee could eventual
- change this, but in many cases (iterators, for example), meeting the
- constraints would involve significant overhead, which would then be
- paid by everyone, including those who didn't use reference counting.
- (For a good discussion of invasive reference counting, see Scott
- Meyers' new book.)
-
- Non-invasive reference counting has significant run time overhead. In
- fact, the overhead is enough to make invasive reference counting the
- prefered method in most cases (IMHO). (For an example of non-invasive
- reference counting, see Barton and Nackman.) My experience suggests
- that in most cases where reference counting is appropriate, I am
- implementing reference semantics for polymorphic objects. In these
- cases, the invasive approach is definitly to be prefered. I suspect
- that if the standard had adapted a non-invasive approach, I probably
- would not have used it anyway. (My own reference counted pointers
- require the referenced object to inherit from GB_RefCntObj.)
-
- Another potential problem: reference counted pointers do not work when
- there are cycles in the reference chain. As such, there actual field
- of use is much more restricted than one would like (for something in
- the standard); I use them because most of my objects fall into
- hierarchial structures, which forbid cycles. But for many application
- domains, the restriction that the references not contain cycles is
- non-trivial. I can imagine that some people would oppose their
- presence in the standard on the grounds that we do not want to
- standardize something that is so intrinsically dangerous; it might
- give people a false sense of security. (By the same logic, of course,
- we should eliminate gets, and even sprintf, from the standard.
- History rules, however.)
-
- In view of these two problems, I myself do not see a real role for
- reference counted pointers in the standard. Note that neither of
- these problems affect auto_ptr. (In theory, I guess, you could create
- a cycle with auto_ptr, but I cannot really imagine the case occuring
- in real code.)
-
- --
- James Kanze Tel.: (+33) 88 14 49 00 email: kanze@gabi-soft.fr
- GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
- Conseils, itudes et rialisations en logiciel orienti objet --
- -- A la recherche d'une activiti dans une region francophone
- ---
- [ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
- Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
- is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
-